Re: personalized /tmp (was: BUGTRAQ ALERT: Solarix 2.x
Andy Poling (andy.poling@jhu.edu)
Wed, 16 Aug 1995 17:23:32 -0400
On Wed, 16 Aug 1995, Scott Barman wrote:
[...]
> What about having a form of chroot so that a user, or a group of users,
> can have their own environments. The only difference is that this
> chroot can be set up to mount system directories read-only (/bin,
> /usr/bin, &c). The limit of their mount is limited to directories
> allowed (for example, you want to allow users access to all of /usr
> with maybe the exception of /usr/etc--this scheme would deny the user
> access to that directory). This way, each user can get their own /tmp
> directory and this problem would not exist.
>
> An administrator would set up their environment before a user logs in.
> The user would have what looks like their own system. Additionally,
> there would be no restrictions to setting up groups of users like
> this, with different home directories as they do now.
>
> (why do I get this feeling this sounds a bit like VM/370?)
Because you are describing VM. However VM does not represent EVERYTHING
with files like UNIX does. You'd need a /dev directory for each user
with 200 device special files in it. And that's just the beginning. If
you've ever tried to set up any sort of semi-complete chroot-ed
environment, you know that you need a million shared libs and executables
etc. It's a royal pain.
> Programs that needed "global" access (i.e., ps) can be written to do
> their own chroot back to the real root to run. Programs like that
> would have to be given permission to do that and design it into the code
> (i.e., no setuid-like behavior).
Here you're stuck. It can't be done. If you could chroot out of a
chroot-ed environment chroot wouldn't be much use, would it...
-Andy
Andy Poling Internet: Andy.Poling@jhu.edu
UNIX Systems Programmer URL: http://jhunix.hcf.jhu.edu/~andy/
Homewood Academic Computing Voice: (410)516-8096
Johns Hopkins University (Balto, MD) UUCP: uunet!mimsy!jhunix!andy